Just a couple of thoughts:

1. What if the names were Slider & SliderUnstyled (rather than SliderStyled & Slider), so that the current import brings in the expected component.

2. What if instead of unstyled, the base component is "minimally styled" - the foundations on which Material Design or any other design system could be layered?

What if the names were Slider & SliderUnstyled (rather than SliderStyled & Slider), so that the current import brings in the expected component.

Totally, will rename them. I am still thinking of potential names for the SliderUnstyled, some options that we may consider apart for SliderUnstyled are: SliderBase, SliderHeadless, SliderVanilla, SliderNaked.

What if instead of unstyled, the base component is "minimally styled" - the foundations on which Material Design or any other design system could be layered?

I'd like ideally the unstyled or base version of component to know nothing about our styling mechanism, so people can opt out and style it from scratch, or even choose a different styling engine, maybe plain css, or something else. On the minimally styled version, I think maybe a better approach to be to export a theme that would provide that, rather than different version of the component. This way we may decide to add "Switch theme" capability for showing different themes on our docs page. These are just thoughts I have at this moment, I may change my mind, so will definitely keep this in mind

I think maybe a better approach to be to export a theme that would provide that

The idea would be to provide a baseline style on which a theme would build, not a complete theme in its own right. (See Reach UI & Reakit). For example: SliderBase - unstyled; Slider - baseline styling; default theme - Material-UI.

The idea would be to provide a baseline style on which a theme would build, not a complete theme in its own right. (See Reach UI & Reakit). For example: SliderBase - unstyled; Slider - baseline styling; default theme - Material-UI.

@mbrookes Would developers use it? For instance, if we look at the open source projects using Reakit and Reach UI on GitHub, e.g WordPress or welcome-ui what can we conclude? Do they use the baseline styles too? Without looking, my intuition would be that they don't and that it goes against the motivation for using the unstyled components in the first place. I would be happy to be proven wrong. We could also ask @gregberge as as happy user of Reakit: How do you best enjoy styling Reakit? Starting from a blank state of from their default styles?

I think that we can solve this baseline style with a second theme, inspired by Tailwind, Bootstrap, and Chakra UI: no shadows, system font, outlined two pixels, etc. Something simple.

Here's an unstyled slider:

(I left the label in so that you can see where the slider is.) Where do you start with customising that?!

But it isn't for me to speak for others – and asking one user what they prefer is the worst kind of anecdata! (No offence to @gregberge).

Instead, I'm proposing an approach which provides unstyled, a baseline, and a fully baked theme as the starting point for customisation - a "win win win" situation.

• If you want to start with nothing, you wrap the *Base components (we have a naming conflict with ButtonBase BTW), probably copying and editing the provided wrapper components as a starting point.

• If you want start with something that functions in the browser, you start with the baseline style components.

• If you want to start with something fully baked, you use the Material (or other) theme.
  ( My main concern would be whether theme based styles could be efficiently pruned without a build-system specific plugin.)

Tailwind, Bootstrap, and Chakra UI

Those are two complete (if minimal) design systems. (Two because Chakra is basically Tailwind, so why mention it?). Instead, I'm suggesting the possibility of components that work "out of the box", but are otherwise design-system agnostic (if unthemed).

Here's an unstyled slider:

@mbrookes True. I imagine the problem would be identical to many components. If you take the data grid, good luck if you start from a blank state like the slider. We could ask developers on #6218. This is an interesting source to benchmark: JedWatson/react-select#2706.

I wonder if a baseline theme, something that is easier to customize really exists for the slider or the data grid. Where would the simplification happen and make a non-negligible difference?

Maybe it's about the inversion of control, maybe if we provide a simple demo with the styles exposed, using the unstyled slider, we would hit the target 🎯.

maybe if we provide a simple demo with the styles exposed, using the unstyled slider, we would hit the target

That could be a good middle ground. 👍

I have turned the above exploration into #22435. I don't understand how the server-side works with third-party packages without the componentId of styled-components. It seems to be just fine but no idea how.

I have looked at emotion integration with Next.js. I don't think that the current setup is OK:

https://validator.w3.org/nu/?doc=https%3A%2F%2Fdeploy-preview-22435--material-ui.netlify.app%2Fcomponents%2Fslider-styled%2F

I have tested, we can solve the issue with the "official" integration example. It uses a custom cache to step emotion to inject CSS inside the body and an extractor function to inline it in the head.

@Andarist are the imports going to change in emotion v11? Are you aware of this line?

I have looked at emotion integration with Next.js. I don't think that the current setup is OK:

We are aware about this validator reports but this doesn't have any downsides in practice. This strategy is allowing the so-called 0 config SSR because we can just render (and stream the result!) without any extra post processing steps. If you want style elements to be put in <head/> this requires rendering the whole thing first and then parsing the outcome and moving things around so the adjusted output can be shipped to the client. We provide a package for all of this but it becomes way less 0 config if you go that route.

@Andarist are the imports going to change in emotion v11?

Yes, but only a little bit and we provide a codemod for this. Changes are - different pkg name (@emotion/core -> @emotion/react) and what has been previously in emotion-theming package is now exported from @emotion/react. We are close to shipping v11 so I assume this won't affect you much because you will be able to "migrate" before your stuff hits the stable mark, right?

Are you aware of this line?

I assume that this is pretty much equivalent of:

import createCache from '@emotion/cache'
const cache = createCache({ key: 'mui' })
cache.compat = true

The only utilize the builtin cache from emotion that has this flag already set. It's a flag suppressing some warnings that are in place to validate if the rendered styles are compatible with 0 config SSR. If one is not interested in that they can set this flag and we assume that the non-0 config SSR approach will be used by the consumer.

We are aware about this validator reports but this doesn't have any downsides in practice.

I have found whatwg/html#1605 on this matter. It might not have downside effects in practice, however, I have a concern with the noise it creates in the output, making it harder for us to identify other fails in https://validator.w3.org/.

@oliviertassinari improved the next.js + emotion integration

was fixed with those changes 👍

This PR has a lot of comments and I can't find the one that I would like to comment so... just going to do it here.

I've consulted Mitchell on why react-select specifies @emotion/core as a dep rather than a peerDep:

1. it's mainly to create less friction - but if pkg managers start to auto-install peer deps then this might change in the future
2. it's somewhat safe in their case because they don't expose theme anywhere, so at least mismatch on this singleton can't cause any issues
3. caches can mismatch, but the worst case scenario some styles can get injected twice to the document - so they have decided that it's not a big deal
4. this can be a problem if one uses a custom CacheProvider but they consider such people to be advanced users and that they should take care of ensuring that there is only a single @emotion/core in the dep tree, using yarn deduplicate, resolutions, or whatever

I've consulted Mitchell on why react-select specifies @emotion/core as a dep rather than a peerDep:

It can also lead to bundling @emotion/core twice if app devs don't pay attention to their lockfile. I have to check with berry devs how their status is on automatic peer deps but we can't really rely on it as long as yarn v1 exists. Though once npm starts doing it my prototyping concern is largely satisfied since prototyping usually uses the latest tooling anyway.